Many computer system customers require systems to be available on a seven-day, twenty-four hour basis. One way to provide this high availability is through redundancy so that no component is a single point of failure. In the case of an AIX operating system, i.e., the International Business Machines Corporation's version of the UNIX operating system, redundancy of the operating system image itself is provided via "mirroring" the operating system to separate physical volumes. However, "mirroring" of the operating system on AIX does not lend itself to mirroring on a distributed computer system such as a RISC System/6000 (RS/6000) Scalable POWERparallel Systems (SP) distributed computer system available from International Business Machines Corporation of Armonk, N.Y.
One particular problem in mirroring operating system images on the SP is that the SP has no central point of control for mirroring. No "central point of control" means there is no way to collect and display customer directives regarding mirroring, there is no way to apply mirroring short of logging on to every SP node. Once mirroring is initiated, there is no data available on which nodes are using mirrored volume groups, nor if any nodes are in a failover condition.
Conventionally, if a customer wishes to mirror volume groups, the customer would have to use, for example, IBM Parallel System Support Program (PSSP version 2.1) to install the nodes without mirroring initiated. Post-installation, the customer would log into the node to enter the set of commands to initiate mirroring. The customer would then write an additional short script that would set the bootlist of the node each time the node is booted to reflect the mirrored volume group presence in the list of bootable devices. The customer would then have to repeat this procedure for each node that mirroring is to be initiated on. Once mirroring is initiated, the customer would have to log on to each node to determine which nodes are using mirrored volume groups, and if any node has failed over to a mirrored volume group.
As a related problem, alternate volume groups may need to be created on one or more nodes of the system. A customer may require an alternate volume group when the customer needs to run multiple different copies of the operating system at different times, without forcing a re-install of the node. Different copies of the operating system might be required for different levels of device driver support, or to have "secure" versus "unsecure" levels of data at highly secure installations. Alternate volume groups may provide many of the same problems on the SP as does mirroring. This is again because there is no central point of control for alternate physical volume administration on the SP.
Conventionally, if a customer wishes to use alternate volume groups, for example, to boot a node from different versions of the AIX operating system, the customer would need to enter information via a command or System Management Interface Tool (SMIT) interface to designate the new volume as the volume to install. The customer would then install the alternate volume using, for example, PSSP software. If the customer wishes to change the node to boot from the other alternate device, the customer would have to manually log into the node to modify the bootlist of the node and then reboot the node. As in mirroring, there is no method of determining which nodes are using alternate volume groups short of logging on to every node.
In view of the above, the present invention comprises a method/system of centrally administering alternate and mirrored volume groups of the nodes in a distributed processing system.